Promise.all at line 37 will reject if any single fetch fails, causing all five time-series requests to lose their results — even the ones that succeeded. Consider using Promise.allSettled instead, so successful responses are still displayed even if one endpoint fails. For example:

const results = await Promise.allSettled([...]);
results.forEach((r, i) => { if (r.status === 'fulfilled' && r.value.success) { /* assign */ } });

Bug: The socket plugin provides the instance as $socketio (see frontend/plugins/socketio.ts:227: nuxtApp.provide("socketio", socket)), but this code destructures it as $socket. Since $socket will always be undefined, the Socket.IO real-time stats subscription (join-admin-room emit and admin-stats-update listener) will never be set up.

Change const { $socket } = useNuxtApp() as any; to const { $socketio } = useNuxtApp() as any; and update all references from $socket to $socketio on lines 78, 79, 83, 89, and 90.

The failedSources count is hardcoded to 0 (0::int AS failed on line 197), meaning the overview summary will always report 0 stale sources. However, the getSyncHealthData() method (lines 231-233) properly computes stale status using a 72-hour threshold. This inconsistency causes the summary bar in the frontend (showing failedSources as the stale count) to always show "0 stale" even when the detailed sync table shows stale entries.

Consider computing stale sources in the SQL query using the same 72-hour threshold, e.g.:
COUNT(*) FILTER (WHERE data_type NOT IN (...) AND connection_details->'api_connection_details'->'api_config'->>'last_sync' IS NOT NULL AND ... < NOW() - INTERVAL '72 hours')::int AS failed

The AdminStatsProcessor introduces multiple query methods and status computation logic (e.g., stale detection via 72-hour threshold, sync health classification), yet no tests are included. Other processors in this codebase have corresponding test files (e.g., AuthProcessor.test.ts, DataModelProcessor.unit.test.ts, UserManagementProcessor.test.ts). Consider adding unit tests to cover at least the getSyncHealthData status classification logic and the getTimeSeriesData metric validation/sanitization.

Critical: When encryption is enabled (the default in production), the connection_details column stores encrypted JSONB with the structure {"version":1,"iv":"...","authTag":"...","encrypted":"..."} — not the original nested structure. This means the JSON path connection_details->'api_connection_details'->'api_config'->>'last_sync' will always return NULL for encrypted rows, causing all API-integrated sources to show as "never synced" in both the summary and the detail table.

To fix this, you need to fetch data sources through TypeORM (which applies the decryption transformer automatically) rather than using raw SQL with JSON operators on the encrypted column. For example, use manager.find(DRADataSource, { relations: ['users_platform'] }) and extract last_sync from the decrypted connection_details in application code. The same issue affects getSyncHealthData() (line 217) and querySyncHealthSummary() (lines 193-194).

Same encryption issue as in getSyncHealthData(): the JSON path connection_details->'api_connection_details'->'api_config'->>'last_sync' will always return NULL when the column contains encrypted data (which is the default in production). The never_synced counter will therefore be inflated, counting all API-integrated sources as "never synced" regardless of actual sync status. Use TypeORM entities with the decryption transformer instead of raw SQL JSON operators on this column.

The donut chart branch returns early at line 71 without setting the cleanup callback. For the line and bar chart types, cleanup is set at lines 142–144 to remove the SVG. This means that when the data changes for a donut chart, the old SVG is only removed via container.value.innerHTML = '' (line 20), but cleanup?.() on line 18 does nothing because it's still null from the previous donut render. While innerHTML = '' covers re-renders, the inconsistency could cause issues if cleanup logic is extended later. Move the cleanup = () => { svg.remove(); } assignment right after the SVG is created (after line 34), so all chart types benefit from it consistently.

redis.keys() is an O(N) operation that blocks Redis while scanning all keys. While this is an admin-only endpoint and the codebase uses redis.keys() in other places, consider using SCAN (e.g., redis.scanIterator({ MATCH: 'dra:ai:*session*' })) if the keyspace grows large. This is especially relevant here since this endpoint is called on every dashboard load and via Socket.IO live refresh, potentially creating more frequent calls than the other redis.keys usage sites (which are for cleanup/deletion tasks).

The useAdminTimeSeries composable is defined and exported but never used anywhere. The admin dashboard page (admin/index.vue) fetches time-series data directly via its own fetchAllSeries function using inline $fetch calls. This dead code adds confusion for future maintainers. Either remove this unused composable or refactor the page to use it instead of duplicating the fetch logic.